IBIS Macromodel Task Group Meeting date: 25 October 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Jared James Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Yifan Ding Rivos Yansheng Wang SAE ITC Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Waymo: Zhiping Yang Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that he had removed Chulsoon's Pre-driver PSIJ Sensitivity BIRD from the agenda because the BIRD had been officially submitted. - Bob asked whether we should cancel the next week's meeting because of the upcoming Asian IBIS Summits, but the group decided not to cancel. ------------- Review of ARs: - Arpad to send out draft0.4 of the clock_times clarification BIRD. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 18th meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: clock_times clarification BIRD draft: Arpad had prepared a presentation to illustrate the issue for which he and Fangyi had added the language: The smallest clock time value in the clock_times vector shall never be smaller than the starting time of the waveform segment in each AMI_GetWave call. Arpad's presentation showed clock and data waveforms and illustrated clock times returned by the DQS model when Rx_Use_Clock_Input is set to "Times" in the corresponding DQ model. Arpad first focused on the case in which the DQS model returned a clock time at the end of one block that was shifted right, i.e., delayed, so that it actually corresponded to the next block of data waveform. He said this case was not problematic, since the EDA tool or DQ model could buffer the clock time(s) for use with subsequent blocks of data. Arpad then illustrated a case in which the first clock time returned by the DQS model had been shifted left, i.e., advanced so that it corresponded to the previous block of waveform data. Arpad said this was the problematic case that caused the "causality" issue because the previous block of data had already been processed. The DQ model, for example, already had to process and return the previous block of data waveform. So, buffering wouldn't solve the problem. Walter asked whom we are prohibiting from doing something with this language. Arpad said the language is telling the model maker not to return a clock time value smaller than the starting time of the block of waveform data. Walter said the language is unnecessary. He said the model maker is responsible for making their DQS and DQ models work together. The EDA tool can't do anything about it anyway. All the EDA tool does is move the clock_times output of the DQS model into the clock_times input of the DQ model (in the "Times" case). Walter gave an example of a block of data made up entirely of zeros except for a single lonely one at the end of the block. In general, that lonely one will come back with the next GetWave call. Walter said the amount of delay depends upon the filter. Say you have a 4 tap DFE, and your first block of data waveform corresponds to 100 bits. The returned waveform might only have used 96 of the input bits, with the last four not appearing until the return of the next GetWave call. The model would know to buffer as many bits from the first call (e.g., 4 in this case) as necessary for processing at the beginning of the second call. So, the DQS model could return clock times corresponding to the last 4 bits of the first block of waveform data when it processed the second block of waveform data. Walter acknowledged that models probably wouldn't be shifting the returned clock times into previous blocks anyway, but he said there's no reason to introduce this language and restrict the model maker. He said the only thing we have to state is that the EDA tool takes the output clock times from the DQS (Clock) model and passes them into the DQ (Data) model. Randy said the specification already does that. Walter and Randy agreed that the other portions of this new proposal from Arpad are helping clarify the requirements. Arpad said he would rethink the need for this statement restricting the clock times values returned. He asked everyone to provide their thoughts and comments via the email reflector. - Ambrish: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 01 November 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives